Business Domain Services
Registries answer who and where. Business domain services answer what happened and what should happen next. In OpenHIE they sit behind the interoperability layer alongside the registries, and each owns one domain of health business data.
The architectural rule is the same as everywhere else in this ecosystem: one service is the source of truth for its domain; everything else holds copies and knows it.
Shared Health Record
A longitudinal, normalised clinical record assembled from the point-of-service systems that feed the exchange. It is what makes continuity of care possible when a patient moves between facilities.
What it holds — encounters, conditions, observations, medications, immunisations, procedures, allergies, care plans, and the provenance of each.
What it does not hold — the operational detail of any one system. A shared health record is not a backup of every EMR; it holds what other providers need in order to care for the patient.
Implementation. Usually a FHIR server constrained by national profiles. The design questions that matter:
| Question | Why it decides the architecture |
|---|---|
| Which resources are in scope? | An unbounded SHR never reaches production. Start with the summary set — problems, medications, allergies, immunisations, key results. |
| Push or pull? | Push (point-of-service sends on save) gives a complete store and simple queries. Pull (federated query at read time) avoids duplicating data and keeps the source authoritative. See centralised vs federated. |
| How is a duplicate handled? | The same encounter arriving twice, or a record later linked to a different patient after an MPI merge. Both will happen. |
| What is the retention rule? | Clinical retention periods are long and legally defined; storage growth is not optional. |
| How is access authorised? | Purpose of use, care relationship, consent. A shared health record without an authorisation model is a breach waiting for a date. |
The merge problem. When the client registry merges two identities, every record in the SHR attributed to the losing identifier must follow — and must be reversible, because merges are sometimes wrong. Design this before go-live, not after the first incident.
Health Management Information System
Aggregate reporting and analysis: indicators by facility, district and period, used for programme management and resource allocation. Typically DHIS2.
Boundary with the SHR. The SHR is individual-level and operational; the HMIS is aggregate and managerial. Two ways to connect them:
(a) Facility-computed aggregates
EMR ──aggregates──▶ IOL ──▶ HMIS
Simple; the facility owns its numbers; hard to audit or re-cut
(b) Central computation from individual data
EMR ──events──▶ IOL ──▶ SHR / warehouse ──indicators──▶ HMIS
Consistent definitions; re-cuttable; requires individual data centrally,
with the governance and consent that implies
Option (b) is analytically stronger and politically harder. Many countries run both, which is defensible only if the indicator definitions are shared — two sources computing the same indicator differently is worse than one source computing it badly.
Tracker programmes blur the line: DHIS2 Tracker holds individual-level data, which makes it a point-of-service system as well as the HMIS. That is workable, but it should be a stated decision with an ADR, not an accident of scope creep.
Logistics Management Information System
Stock on hand, requisitions, receipts, distribution, cold chain and consumption reporting. See supply chain.
Interoperability dependencies. An LMIS needs the facility registry (delivery points must be the same facilities the clinical systems use) and a product catalogue — the shared list of commodities, with their codes, pack sizes and units. Without a shared catalogue, consumption cannot be compared across systems and stock-out analysis is unreliable.
The valuable link is dispensing data from the clinical systems: actual consumption rather than issued quantity, which produces far better forecasting. This requires medication coding to be consistent between the EMR and the LMIS — one of the strongest practical arguments for a national drug terminology.
Open source: OpenLMIS, and the logistics modules of several EMR platforms.
Finance and insurance
Eligibility checking, claims submission and adjudication, provider payment. See health financing.
What it needs from the exchange:
- Verified client identity — eligibility is checked against a person
- Verified provider and facility identity — payment goes to a contracted entity
- Coded services and diagnoses — normally ICD plus a national procedure or service code list
- Clinical evidence for adjudication, which is where the consent question becomes sharp: an insurer's need to verify a claim is not the same purpose of use as a clinician's need to treat
Open source: openIMIS. FHIR provides Coverage, Claim, ClaimResponse,
ExplanationOfBenefit and CoverageEligibilityRequest, though national claim
formats often remain X12 or a local standard.
Design warning. Financing systems create strong incentives to record data in particular ways. If the same coded data drives both clinical care and reimbursement, expect the reimbursement incentive to shape the clinical record. This is an architecture problem as much as a policy one — it argues for keeping the clinical assertion and the billing assertion distinguishable, with provenance on both.
Other domain services
Depending on the ecosystem's maturity:
- Terminology service — sometimes classified as a registry, sometimes as a domain service. See terminology services.
- Consent service — recording and enforcing the patient's sharing decisions; see consent and trust.
- Clinical decision support — computable guidelines exposed to point-of-service systems, typically via CDS Hooks and CQL; see SMART Guidelines.
- Surveillance service — case-based and event-based reporting; see public health surveillance.
- Notification / messaging service — appointment reminders, results notification, campaign messaging, over SMS, USSD or push.
Sequencing
Do not build all of these. A workable order for a country starting out:
- Facility registry — least contentious, unblocks everything else
- One domain service with a real user — usually HMIS, because it already exists
- Client registry — as soon as any individual-level exchange is needed
- Shared health record — only once at least two systems will both write to and read from it
- Terminology service — before the hard-coded maps become load-bearing
- Consent, financing, logistics — as the programmes demand them
A shared health record built before anyone reads from it is a very expensive write-only database.
References
- OpenHIE architecture — https://ohie.org/
- DHIS2 — https://dhis2.org/
- OpenLMIS — https://openlmis.org/
- openIMIS — https://openimis.org/
- HL7 FHIR financial resources — https://hl7.org/fhir/financial-module.html